release: what a release note has to say is decided in one place - #43
Merged
Merged
Conversation
Two workflows had an opinion about the same sentences. release.yml wrote them into the note it generates, and verify-release.yml held the published page to a list written out inside itself. Nothing compared the two. Change the predicate URI in the generator alone and the check goes red on a correct page, and somebody debugs the release page. Change it in the check alone and a page telling people the wrong command sails through. This is the shape closed for archive settings a few hours earlier, and it was sitting in a second corner. The list moves to .github/release-note-must-say.txt and one script reads it. release.yml now checks the note it just generated, which turns a generator that quietly stopped saying something into a failed build rather than a published page that goes red hours later, where fixing it is a public edit. The script reports every missing line rather than the first, for the reason the verdict step already gives: a person reads a release page once. Measured before and after, by hand, because running bash from a Go test on a machine with three of them starts the wrong one: the published v0.2.0 note -> fails, naming all three a note carrying all three -> passes an empty list -> refused, rather than passing on any note Two guards, three mutations, all caught. One holds both workflows to reading the list, because deleting a call removes a check with nothing going red. The other holds the generator to saying everything the list asks for, asked on a pull request rather than on a tag - the one moment nobody wants a surprise. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two workflows had an opinion about the same sentences.
release.ymlwrote them into the note it generates, andverify-release.ymlheld the published page to a list written out inside itself. Nothing compared the two.Change the predicate URI in the generator alone and the check goes red on a correct page, and somebody debugs the release page. Change it in the check alone and a page telling people the wrong command sails through.
What changes
The list moves to
.github/release-note-must-say.txt, and.github/scripts/note_says.shreads it for both halves.release.ymlnow checks the note it just generated. A generator that quietly stops saying one of those sentences becomes a failed build rather than a published page that goes red hours later, where fixing it is a public edit.The script reports every missing line rather than the first, for the reason the verdict step already gives: a person reads a release page once.
Measured
By hand, because running bash from a Go test on a machine with three of them starts the wrong one:
v0.2.0noteGuards
TestWhatAReleaseNoteHasToSayIsDecidedInOnePlaceholds both workflows to reading the list. Deleting a call removes a check with nothing going red, which is the silent kind.TestTheGeneratedReleaseNoteSaysEverythingTheListAsksForholds the generator to saying everything the list asks for. Asked on a pull request rather than on a tag - the one moment nobody wants a surprise. It reads only the block that builds the note, so a substring found elsewhere in the workflow cannot answer for it.Three mutations, all caught.
Checks
preflight --quickgreen on all twelve,tools/probes/workflow-shell.pyclean on everyrun:step of both workflows,stalenessclean at 733 entries.🤖 Generated with Claude Code